Dynamic Workers

SE reference. What it is, when to position it, how it differs from Gateway and AI Gateway, and the customer-facing pitch.
What it is When to position vs Gateway / AI Gateway How egress control works Customer scenarios Gotchas

What it is, in plain English

Dynamic Workers let you spin up a fresh, isolated Worker at runtime to execute code you do not trust. Think of it as a sandbox: arbitrary code goes in, runs in a contained environment, and you control exactly what it can see and reach.

The headline use cases Cloudflare ships it for:

The mental model: Workers for Platforms is for tenants who deploy a Worker once and it stays. Dynamic Workers is for code that gets spun up, executed, and torn down per request. Each invocation is a fresh sandbox.

When to position Dynamic Workers

Good fit:
Bad fit:

Dynamic Workers vs Zero Trust Gateway vs AI Gateway

This is the question that came up on the Khadija thread. All three products touch "controlling what something can reach," but they solve different problems.

What the customer is doingUse this
Employees using ChatGPT, Claude.ai, Copilot in the browser; we want to block or audit some of thatZero Trust Gateway (SWG)
Our app calls Anthropic/OpenAI APIs and we want caching, rate limiting, cost visibility, fallback to a second providerAI Gateway
Our agents run code we did not write (LLM-generated, customer-uploaded) and we need that code sandboxed and locked down on what it can call out toDynamic Workers
Multiple of the aboveCombine them. Gateway for employees, AI Gateway for app-to-LLM, Dynamic Workers for the agent sandbox
How the Khadija customer maps: They said "controlling egress of where employees are going while they vibecode using Anthropic/OpenAI." Adam's read in the thread was right — that is a Zero Trust Gateway problem, not a Dynamic Workers problem. Their employees are using managed agents (Claude Code, ChatGPT). Filter the traffic at the SWG layer. Done.

Dynamic Workers only enters the picture if they later build something where end-users upload agent code that runs on their platform. Then sandbox isolation + egress control becomes the right shape.

How egress control actually works (the part that lands with engineers)

This is what we tell a technical buyer who asks "how do you actually stop the sandboxed code from reaching the internet?"

Three options, ordered from most restrictive to most flexible:

Option 1: Block everything

Set globalOutbound: null when loading the dynamic Worker. Every fetch() and connect() call inside the sandbox throws an exception. The agent has zero internet access. You then hand it specific capabilities via bindings — "you can post to this chat room, you can read from this KV namespace, that is all you can do."

const worker = env.LOADER.get("agent-1", async () => ({
  mainModule: "agent.js",
  modules: { "agent.js": code },
  globalOutbound: null,    // block everything
  env: {
    CHAT_ROOM: chatRoomStub,  // explicit capability
  },
}));
When to use: the most secure pattern. The agent gets only what you hand it, nothing else.

Option 2: Intercept every outbound request through a gateway Worker

Define a WorkerEntrypoint class in the loader that acts as a gateway. Every outbound request the sandbox makes routes through that class first. You inspect, allow, block, modify, or inject credentials.

export class HttpGateway extends WorkerEntrypoint {
  async fetch(request) {
    const url = new URL(request.url);
    if (url.hostname !== "api.openai.com") {
      return new Response("blocked", { status: 403 });
    }
    // Inject API key here — sandbox never sees it
    const headers = new Headers(request.headers);
    headers.set("Authorization", `Bearer ${this.env.OPENAI_API_KEY}`);
    return fetch(request, { headers });
  }
}

// In the loader:
globalOutbound: ctx.exports.HttpGateway(),
When to use: when the sandbox uses normal HTTP client libraries (which expect fetch() to work) and you want allow-list policy. This is what the live demo does.

Option 3: Per-tenant credential injection with props

One HttpGateway class, many sandboxes, each with their own credentials. Pass props when you create the stub, gateway reads them via this.ctx.props.

// Per-tenant gateway
globalOutbound: ctx.exports.HttpGateway({
  props: { tenantId: "acme", apiKey: ACME_KEY },
}),
When to use: SaaS platform with many customers, each with their own API key, each running their own agent code. Clean isolation per tenant.

Customer-facing scenarios

"We are building a coding agent that runs LLM-generated Python/JS"

Dynamic Workers is a strong fit. The agent loop ends with "execute this code." You don't want that code to have shell access to your servers. Sandbox it, allow it to call back to your LLM for next steps, block everything else.

"Our customers upload automations that integrate with their Slack/Salesforce/whatever"

Dynamic Workers with custom bindings. You expose this.env.SLACK and this.env.SALESFORCE capabilities. The customer's automation code calls those methods. Your loader Worker holds the OAuth tokens, the customer's code never sees them.

"We need to give an AI Code Interpreter to our users"

Classic Dynamic Workers play. Each user message that triggers a code execution spins up a fresh sandbox. Per the docs, can save up to 80% in LLM token cost vs streaming data through the model.

"We want to block employees from using Claude.ai during work hours"

Not Dynamic Workers. This is Zero Trust Gateway. Set an HTTP policy that blocks claude.ai by category or hostname. Done.

Gotchas and honest disclosure

Links